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Online Payer Authentication Service 

This sipplication claims priority of U.S. provisional patent application No, 
60/199,727, filed April 24, 2000 entitled ''Visa Payer Authentication Service 
5 Description," which is hereby incorporated by reference. 

FIELD OF THE INVENTION 

The present invention relates generally to financial transactions, and more 
1 0 specifically to authenticating the identity of payers during online transactions. 

BACKGROUND OF THE INVENTION 

During a payment transaction using a payment card (e.g., a credit, debit, or 
stored value card), it is important to verify a cardholders ownerahip of an account to 

15 avoid a variety of problems, such as unauthorized use. Payer authentication is the 
process of verifying a cardholder's ownership of an account The most common 
method to authenticate a cardholder's ownership of an accotmt occuins routinely at a 
point of $ale during what is called a "card presenf transaction. A card present 
transaction involves a merchant's representative taking the cardholder's card, swiping 

20 it though a payment card terminal to verify account status and credit line availability, 
. and th^ checking to see that the signature on the back of the card matches the 
purchaser's signature. If flie merchant follows specific guidelines for this type of 
transiaction, the merchant will be guaranteed payment for the amoimt authorized less 
discount and fees. A sendee provider such as Visa International Service Organization 

25 . (or service organization) rnay provide these specific guidelines. 

"Card not present" transactions, on the oUxor hand, such as those occurring 
online, through tiie mail, or over the tel^hone, involve payments that are not 
guaranteed to the merchant. No guarantee is provided primarily because the payers 
are not authenticated in such non face-to-face transactions, thereby allowing many 
30 risks to accompany the "card not presoaf ' transactions. Such risks involve issues 
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such as chargebacks of payment transactions to online merchants, fraud for both 
merchants and cardholders, increased exception item processing e:xpenses for bardcs, 
and an increased perception tiiat buying goods and services online is not safe and 
secure, which may keep some consumers J&om buying online. .Specific examples of 
5 risks include the unautiborized use of stolen account information to purchase goods 
and services online, fabrication of card accoimt numbers to make fraudulent online 
purchases, and extraction of clear text accoiont information from network traffic. 

Given the continued expected high growth of electronic commerce, it is 
important to provide methods to authenticate payers. This will benefit all payment 

10 system participants including cardholders, merchants, and financial institutions. 
Authenticating the payer during online purchase transactions will reduce the levels of 
fraud, disputes, retrievals and charge-backs, which subsequCT.tly will reduce the costs 
associated with each of these events. Authenticating the payer also addresses 
consumer security concerns and tlierefore will lead to increased online sales. Prior 

15 systems used to authenticate consumers during online transactions have not been 
widely adopted because tiiese systems were difficult to use, had complex designs, 
required significant up-front investment by system participants and lacked 
interoperability. Certain prior systems additionally required the creation, distribution 
and use of certificates by merchants, cardholdCTS, issuers and acquire Such use of 

20 certificates is known to be quite burdensome. 

In view of the foregoing, a system for authenticating the identity of the payer 
in an online transaction woidd be desirable. Such an authenticating system sAiould be 
relatively easy to implement and use, require a minimal investment of resources, and 
provide a high level of interoperability between the systCTi's participants. 
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BRffiF SUMMARY OF THE INVENTION 

The present inventioii is directed towards an onUne service for authenticating 
the identity of a payer during online transactions. The present invention is relatively 
5 easy to implement and use, requires a minimal investment of resources to implement, 
and provides a high level of interoperability between the system's participants. The 
authentication service of tiie present invention allows a card issuer to verify a 
cardholder's identity usiag a variety of authentication methods, such as the use of 
passwords. Also, the only system participant requiring a certificate is the issuing 
10 financial institution. The authentication service can also provide authentication 
results to the merchant in real time during the checkout process. 

hi a first embodiment, the invention is directed toward the use of a traditional 
card, such as credit cards, debit cards, identification cards, etc. One aspect of the jBrst 
embodiment pertains to a method for authenticating the identity of a cardholder 
15 during an onhne transaction. The method involves merchants querying a card issuer 
managed access control server to determine if said cardholder is emrolled in a 
payment authentication service, requesting a password firom the cardholder, verifying 
said password, and notifying a merchant of the authenticity of the cardholder if the 
password entered by said cardholder is autiiCTiticated. 

20 In a second embodiment, the invention is directed towards the use of an 

integrated circuit card (also known as a smart card or chip card). One aspect of the 
second embodiment pertains to a method for authenticating the identity of a 
cardholder utilizing a chip card. This method iavolves verifying that said cardholder 
client device includes a chip card reader and then prompting said cardholder to enter 

25 said chip card into the chip card reader. After the chip card reader receives the chip 
card, the chip card goaerates a cryptogram which is then sent to the access control 
server. The access control server then independently g^erates a second cryptogram 
based upon information in the chip card and compares the chip card cryptogram to the 
second cryptogram. If the two independently generated cryptogranis match, then the 

30 authenticity of the card is verified. 

The service of the present iavention presents many advantages. For example, 

the authentication service lays the foundation for establishing guaranteed payments 

for merchants involved with "card not present" transactions. Additionally, the 
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authentication service will reduce chargebacks, frauds, and exception item 
processing. These and other features and advantages of the present invention will be 
presented in more detail in the following ^ecification of the invention and the 
accompanying figures, which illustrate by way of example the principles of the 
5 invention. 



4 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The invCTition, together with further advantages thereof, may best be 
understood by reference to the following description tdcen in conjunction with the 
accompanying drawings in which: 

5 FIG. 1 schematically illustrates one embodiment of an infrastructure 

architecture that can siipport the Payer Authentication Service (PAS). 

FIG. 2 illustrates the process through which a cardholder regist^s with PAS 
according to one embodiment of the present invention. 

FIG. 3 illustrates one embodiment of an Internet web page in which a 
10 cardholder can enter information during the enrollment process for PAS. 

FIG. 4 illustrates a PAS authenticated payment transaction according to one 
embodiment of the present invention. 

FIG. 5 illustrates an exemplary window that prompts the cardholder for his or 
her password. 

15 FIG. 6 illustrates exemplary messages that are sent during the payment 

transaction superimposed over the PAS architecture. 

FIG. 7 illustrates the message flows on the centralized PAS architecture 
according to a centralized embodiment of the present invention. 

FIG. 8 illustrates the centralized payment flow that occurs between the 
20 cardholder client device, the PAS, and the merchant system, according to the 
centralized embodiment of the present invention. 

FIG. 9 illustrates the enrollrnent flow in the distributed PAS architecture 
according to a distributed embodiment of the present invention. 

FIG. 10 illustrates flie payment flow in the distributed PAS architecture 
25 according to the distributed embodim^t of the present invention. 

5 
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FIG. lOA provides a high-level system architecture view of one embodiment of 
the chip card payer authorization service. 

FIG. 11 is a flow chart describing one example of a payment transaction nsing 
the chip card embodiment of the payer authentication service. 

5 FIG. 12 illustrates a system architecture view of the chip card authentication 

process according to one embodiment of the present invention. 

FIG. 12A illustrates a detailed flow of messages between the chip card, the 
cardholder client system, and the issuer's access control server. 

FIG. 13 illustrates a system diagram of the components utilized in the access 
1 0 control system CT^bodiment of the payer authentication service. 

FIG. 14 illustrates a telecommunications network suitable for implementing an 
embodiment of the present invention. 

FIG. 15 illustrates ^stems housed within an interchange center to provide 
online and offline transaction processing. 

1 5 FIG. 1 6 illustrates another view of the components of the telecommunications 

network. 

FIGS. 17A and 17B illustrate a computer system suitable for implementing 
embodiments of the present iuvention. 
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DETAILED DESCRIPTION OF THE INVENTION 

The present invention will now be described in detail with reference to a few 
preferred embodiments thereof as illustrated in the accompanying drawings. In the 
5 following description, numerous specific details are set forth in oider to provide a 
thorough understanding of Ihe present invention. It will be apparent, however, to one 
skilled in the art, that the present invention may be practiced without some or all of 
these specific details. In other instances, well known operations have not been 
described in detail so not to unnecessarily obscure the present invention, 

10 To begin with, a high-level description of Ihe authentication process used by 

the Payer Authentication Service (PAS) will be provided. Later in this disclosure, a 
more detailed description of the authentication process and other processes, such as 
system setup and customer registration and specific message flows, wiU be provided. 
As explained in the previous sections of this disclosure, PAS is designed to 

15 authenticate cardholder accoimt ownership during online purchase transactions. PAS 
will be used, for example, when a cardholder shops online, adds items to a shopping 
cart, proceeds to the online merchant's checkout page, and completes the online 
merchants checkout forms. PAS can also be used in various transactions when a 
trusted party auttienticates the identity of an individual or entity for the benefit of a 
20 third party. As is coromonly known, the trusted party usually accepts legal 
responsibility for the authentication of the individual or entity to the third party. For 
example, PAS can be used to authenticate a financial institution's customers when 
accessing an Internet web site to complete an online form. PAS can also be used in 
aspects of retail banking such as debit cards, purchase cards, stored value cards, as 
25 well as Wholesale banking, the medical business, the insurance business, ttie 
brokerage business, etc. ID cards can also be used with PAS. For example, AAA 
may use PAS to authenticate the identity of its customer, or a telephone card 
cotxipany can use PAS to authenticate the identity of Ihe user of a specific card. 

PAS can perform its authentication processes after the consumer decides to 
30 buy his or her desired products or services, for example, after the consumer chcks a 
""buy" button. PAS can also begin its authentication process at various other times ia 
the consumer's purchase transaction, not only after the *T5uy" button is clicked. The 
authentication process is conducted mostiy in a transparent mode to the consumer by 

7 



.0182246A2_L> 



wo 01/82246 



PCT/USOl/13382 



utUizmg software that has been incorporated in several points of a payment netwoik. 
PAS validates participation by the cardholder and the cardholder's financial 
institution and then creates a window in which the consumer can confirm his or her 
identity by requesting a previously register^ password firom the cardholder. If the 
5 identity of the consumer is confirmed^ the payment information and notice of the 
consumer's authentication is sent back to the merchanl Then, as conventionally 
p^ormed, the payment transaction is processed by the merchant For example, the 
m^hant may send an order confirmation m^sage to the cardholder's browser. 



10 HIGH LEVEL SYSTEM DESCRIPTION 

FIG, 1 schematically illustrates one embodiment of an infrastructure 
architecture 100 that can support the PAS. The architecture is divided into three 
domains, the issuer domain 102, the interoperability domain 104, and the acqiiirer 
domain 106. The issua: domain 102 includes components that are primarily 

15 controlled by an issuer. An issuer, for example, can be a financial institution that 
issues payment cards to consxmiers. Specifically, an issuer, or a card issuer, 
personalizes new cards received fi-om a card supplier and then issues these cards to its 
customers. Peraonalization may also be performed by the card supplier or by a 
personalization bureau. In addition to being a financial institution, an issuer rnay be 

20 any suitable issuing entity such as telecommunications network operator, a service 
association, a merchant or other organization, or even an agent acting for an issvier. 
The acquirer domain 106 includes components that are primarily controlled by an 
acquirer. An acquirer, for example, can be a financial institution that enrolls 
merchants in the payment scheme and manages the accounts of merchants. The 

25 acquirer also routes information firom an online merchant to the telecoiiununications 
network. The interoperabiUty domain 104 is supported by the Internet and includes 
conxpopents used by both the issuer and the acquirer. The interoperability domain 
104 is typically managed by the card scheme manage such as Visa. The 
intetop^rabiiity domain 104 can also be supported by a netwotk other than the 

30 Internet 

The issuer domain 102 includes an enrollmoit site 108, an issuer cardholder 
system 110, the cardholder client device 122, an enrollment server 112, an access 

8 

BNSOOCID: <WO ^01S2246A2_L> 



wo 01/82246 



PCT/USOl/13382 



control server 1 14, an issuer or third party identity authentication component 116, and 
an account holder file 118. Optionally, the issuer domain 102 can include an issuer 
file of approved cardholders 120. The enrollment server 112 is a computer that 
manages cardholder enrollment into the PAS service through presenting a series of 
5 questions via a web interface to be answered by the cardholder and verified by the 
issuer. As shown in FIG. 1, the card issuer operates the enrolhnent server 112. 
However, a service organization, such as Visa, may operate tiie enrollment server 1 12 
on behalf of tiie issuer. The issuer may use a web-enabled, interactive "identity 
authentication service" provided by a third party during the enrolhnent process to 

10 help validate a cardholder's identity. The enrollment server 112 is connected via the 
Intemet to the Intemet Payment Gateway Service 124, which is in turn, connected to 
a telecommunications network 126, for example, VisaNet. The Intemet Payment 
Gateway Service 124 allows the enrollment server 112 to communicate with the 
telecommunications network 126. The connection via the Payment Gateway Service 

15 124 allows the enrollment server 112 to query the issuer's autiiorization system 127 
to determine if a cardholder being enrolled has an active card account. Enrollment 
site 108 is an Intemet web site where the cardholder can register to participate in the 
PAS. 

The access control server (ACS) 114 is a computer that has a database of 
20 cardholders registered for PAS containing cardholder account and password 
information. During an oidine payment transaction, the access control server 114 
provides digitally signed receipts to merchants, controls access to PAS, and validates 
cardholder participation in the service. The card issuer or a service organization, such 
as Visa, on behalf of the issuer may operate the access control server 114. While 
25 PAS does not require any additional cardholder software to be used, optional 
cardholder software and hardware may be deployed. The cardholder software may be 
used to support additional authentication techmques such as digital cextijBcates, 
integrated circuit cards (chip cards) and chip card reader, or to verify tiiat the ACS is 
properly associated to the appropriate cardholder client device. Account holder file 
30 118 is a issuer managed database for storing information relating to the cardholders 
that are successfully enroll^ in PAS. 

Cardholder client device 122 is used by the cardholder to participate in PAS. 
Specifically, the cardholder client device 122 can be any device capable of accessing 
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the Internet, such as a personal computer, mobile telephone, a personal data assistant, 
or an interactive cable television. 

The issuer cardholda: system 110 is an issuer controlled system containing 
information about cardholders. This system information contains information 
5 concerning account information, services utilized by the cardholder, etc. Some of the 
information within the issuer cardholder system can be used in the process for 
enrolling cardholders in the PAS. 

Issuer or titurd party identity authentication database 1 16 contains information 
that the issuer or third party already has on file regarding cardholders. Database 116 
10 is used by issuer in the process of enrolling cardholders to verify the id^itily of the 
cardholders. For instance, information entered by cardholders during the PAS 
registration process must match the information already on file in the authentication 
database 1 16 in order for cardholders to successfiiUy register for PAS. Third parties 
can be companies such as Equifax. 

15 The interoperability domain 104 includes a directory server 128, a receipt file 

130 and a receipt manager 131. Directory server 128 routes authentication requests 
from merchants to specific access control serves. The directory server 128 is 
operated by a service organization, such as Visa, The receipt file 130 and receipt 
manager 131 store signed receipts for each authenticated purchase transaction. The 

20 receipt file 130 contains information that verifies which transactions were 
authenticated and provides additional information dming dispute resolution 
processes. The receipt file 130 and receipt manager 131 are operated by a service 
organization. The issuer. Acquirer, or merchant may also maintain a copy of the 
digitally signed receipt. 

25 Acqiiirer domain 106 includes the merchant 132 and the validation server 136. 

A merchant plug-in software niodule 134 resides at the location of the merchant 132. 
The merchant jplug-in software module 134 is a PAS software module that integrates 
into a merchant's electroriic coimnerce web sites. The plug-in software module 134 
provides the interface between ttie PAS and the merchant's payment processing 

30 software. The validation server 136 verifies the digital signatmre of the card issuer 
used to sign the receipt returned by PAS to the m^chant during the payment 
transaction. In altemative embodiments of the present invention, the functionality of 

10 
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the vaUdation server 136 may be mcluded within the merchant plug-in software 
module 134, thus eliminating the need for a separate vaKdation server 136. The 
vaHdation server 136 is operated by the merchant, the acquirer or by a service 
organization. 

5 The infrastructure of the PAS niay be implemented in two separate 

architectural approaches. One approach is a centralized architecture and the second is 
a distributed architecture. The centralized approach requires no software or data to be 
stored on the cardholder's client device. In the distributed architecture, on the other 
hand, PAS software exists on the cardholder's cUent device. This software is 

ip downloaded by the enrollment server to the cardholder client device during the 
enrolhnent process. In the distributed approach, the merchants determine a 
cardholder's participation in the PAS through a mechanism provided by the 
cardholder's system client device. It should be noted that a vendor, a PAS software 
siqipfier, could choose to create the centralized, distributed, or a combination of the 

15 two architectures depending upon the vendor's or th«r customer's specific business 
requirements. FIGS. 7-10 will provide fiirfher detail as to centralized and distributed 
architectures. 

As inentioned earlier, the distributed architecture requires software to be 
stored on the cardholder cUent device. The distributed PAS provides a mechanism 

20 for a cardholder to transfer payment appUcations and persistent data fi-om one 
cardholder client device to another cardholder cUent device. This mechanism 
provides PAS with the ability to authenticate a cardholder's identity when the 
cardholder client device is a different client device j&om the client device that flie 
cardholder accessed durinig the registration process. The PAS system is also capable 

25 of authenticating the cardholder's identification when the current cardholder's cUent 
device is one that the cardholder had not used previously. In other words, cardholders 
can use PAS on more than one client device. At least two methods exist for 
transferring the PAS software between cardholder client devices. The first method 
involves a cardholder using a portable storage medium, such as a floppy disk, to 

30 tranqjort the software. The second method involves the ACS dynamically 
dowidoading the software onto the additional cHent device to be used by the 
cardholder. 
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In some embodiments, PAS can interoperate with other cardholder 
applications^ such as electronic wallets, and PAS can operate conq^atibly with 
electronic commerce niark-up language (ECML Software). PAS also provides 
capabilities to implements dispute resolution procedures. For instance, the PAS 
5 allows the merchant to retain sufBcient information to provide proof of cardholder 
auflientication for the purposes of dispute resolution and chargebacks. 

SBT-UP, REGISTRATION AND AUTHORIZATION DETAILED DESCaEOPTION 

The description will now provide further detail regarding the various phases 
10 from setting up of the PAS to the actual authorization of online transactions. First, 
the procedures required to set up the various system partic^ants such that they may 
operate vsdthin the PAS will be explained. Then the cardholder's process for 
registering with the PAS will be explained. After these phases are described, 
explanation will be provided as to the actual authorization of payment transactions. 

15 Setting up the PAS involves set up procedures for all the participants within 

the system. These participants include entities such as the merchants, financial 
institutions, and cardholders. First, the set up procedures of the online merchants and 
financial institutions will be desc^bed, and then the set up procedures for cardholders 
will be described. 

20 Online merchants who sign \sp with the PAjS receive merchant plug-in 

software modules, such as plug-in software module 134 in FIG. 1. The plug-in 
software module should be specific to the computing platform and commerce server 
software used by the merchant. Financial institutions particq>ating within PAS will 
provide bank logos and marketing designs to be incorporated into their customized 

25 PAS enroUment site template. Acquirers should also provide merchants with a 
service organization certification . authority (CA) root certificate, a service 
organization certification authority SSL certificate for cliCTt authentication, and 
integration support 

Before an Issuer can be set up to use PAS they must obtain a copy o fall PAS 
30 software specified in the Issuer domain and install hardware systems and the PAS 
software. Then, Issuer financial institutions will also provide identity authentication 
policnes and participating BIN information to PAS to be used in cardholder identity 
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verification processes. Optionally, the issuer can provide to the PAS the caidholder 
authentication information for pre-loading into the accoimt holder file 118. Pre- 
loading facilitates large volume support of cardholders. For example, wh^ an issuer 
desires to activate all or most of its cardholders for PAS, the Issuct can send PIN 
5 numbers to all of its cardholders. The PIN nimiber can then be used by each 
cardholder to access his or her preloaded passwords. In this manner, the emroUmmt 
process is expedited because each cardholder need not go through the formal PAS 
enrollment process. After the cardholders use their preloaded password for the first 
time, the cardholders have the option of designating a new and easier to remember 
password. 

Cardholder authentication information includes information such as business 
identification, covmtry code, card account number, card expiration date, cardholder 
name, issuer-specific authentication data specified in the **participating BIN" data 
(e.g., motiier's maiden name), and other information such as billing address, shipping 
address, social security number, telephone number, accoimt balance, transaction 
history, and driver license number. Issuers should also provide accoimt number 
ranges for their card accoimt portfolios and access control server IP addresses (URLs) 
to the directory server. PAS will be offered through bank branded web-sites, which 
will allow cardholders to register with PAS. 

FIG. 2 illustrates the process tiirough which a cardholder registers with PAS 
according to one embodiment of the present invention. As shown in step 1, 
cardholders visit an emrollment server Intemet web site maintained by a financial 
institution, such as an issuer. Cardholders register with PAS by registering their 
credit card account numbers.. Altematively, cardis such as check and debit cards may 
also be registered. Also, cardholders may register one or more cards with PAS. As 
shown at step 2, the cardholder enters information such as a cardholder primary 
account number (PAN), name and card expiration date. Additional information may 
also be entered by the consxuner at this point. For instance, address, e-mail address, 
shopper identification, an account verification value, cardholder-specific password, 
and issuer-specific authentication information may also be entered by the cardholder. 
This information can be entered in a page at the enrollment web site such as page 300 
shown in FIG. 3. 
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After the cardholder enters the requested informatioii at the enroUnieiit site 
108, PAS verifies that the cardholder PAN falls within a card range that is registered 
by the issuer in the directory server 128 of the.IntCTOperability domain 104.. The PAS 
can verify cardholder identities using various methods. First, as just mentioned, the 
5 PAS can verify the cardholder identity through a third party autiientication database 
or through the issuer's own autiientication database. Additionally, verification can be 
performed by using the issuer provided file of approved cardholders 120, by 
transmitting status check authorizations to the issuer, and by comparing responses to 
pre-loaded information provided by financial institutions, 

10 If the PAN is not within an issuer oirolled card range, the enrollment is 

rejected and the enrollment process is terminated. If the PAN is within an enrolled 
card range, an authorisation for one dollar will be submitted through a service 
organization payment network, such as VisaNet, to the issuer financial institution. 
The authorization of the one-dollar transaction allows the issuer to verify the card 
15 account status, verify the address using the Address Verification Service, and verify 
the Cardholder Verification Value 2 (CW2). The CW2 is a tinree-digit number 
. printed on the signature strip on the back of the payment cards. 

If the card is approved, then at step 3, the cardholder will then be prompted 
for additional authentication information to verify the cardholder's identity in an 
20 interactive, real-time^ online session. In some embodiments of the present invention, 
the cardholder can also be requested to enter a password and a *Taint question and 
response" pair that will be used to authenticate the cardholder during the purchase 
transaction. 

As shown in step 4, when the cardholder's identity is verified and the 
25 appropriate responses are retumed, PAS sends an authorization message to the issuer 
financial institution. Then at step 5, fhe enrollment server 112 passes cardholder 
information to the access control server 114 to set up records in the account holder 
file 118 . The account holder file, such as account holder file 118 in FIG. 1, can store 
information such as: financial institution BIN numbers, ac€X>unt numbers, expiration 
30 dates, first and last names, driver's license numbers, billing addresses, social security 
numbers, cardholder passwords, cardholder password questions, cardholder password 
answers, cardholder email addresses, third party identity scores, and other 
information. 
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In some embodiments of the present invention, during the registration process, 
the cardholder can be asked to eater a phrase, called the personal assurance message 
(PAM), that is recognizable to the cardholder. PAM is later presented to the 
cardholder by the issuer during a payment transaction. Since only the issuer knows 
5 the cardholder's designated PAM, the cardholder can be assured that a dialog window 
used with PAS was delivered from the cardholder's issuer. An example PAM is, "the 
sky is blue." 

It should be noted that cardholders require no new client software or devices 
to use PAS. In some cases however, chip card inq)lementations of PAS may require 
10 additional cardholder componoits such as a chip card reader. In a preferred 
embodiment, the consumer registration process utilizes s6cuiity protocols such as 
SSL channel encryption to protect data transmitted across the intemet between the 
cardholder and the enrollment server. 

Also, during the consumer registration or emx>llment process, each financial 
15 institution may display its own "terms of use" and/or "data privacy policy." Each 
financial institution has the ability to require registering cardholders to either accept 

or not accept tiie terms and policies in order to complete the registration process. The 
version numbers of the "terms of use" and/or the "data privacy policy" accepted by 
each consumer should be saved by the financial institutions. 

20 After PAS system participants are set up and the cardholders are registered, a 

payment transaction may be authenticated utilizing PAS. A PAS authenticated 
payment transaction is illustrated in FIG. 4. In step 1 of FIG. 4, a cardholder visits a 
merchant's electronic commerce site on the lutemet After the cardhold^ selects the 
products or services he or she wishes to purchase, the cardholder begins the checkout 

25 process, conapletes the checkout form, and then clicks on a *'buy**butbm. 

After the "buy" button is selected, as shown in step 2 of FIG. 4, the merchant 
plug-in software module is activated and then performs a verification process to 
determine whether the cardholder's specific account is registered with the PAS. 
There are various methods by which the merchant plug-in software module can 
30 determine if the cardholder is registered with PAS. For instance, a two-step process 
in which the directory server and then the ACS accociated with the cardholder is 
checked, a process where only the ACS is checked, and a method in which the 
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merchant caa check a cache memory containing the same information held in the 
directory server. 

A description of the two-step process will now be provided. In the first step, 
the merchant plug-in software module identifira the card accomit nmnber and quoies 
5 the directory server 128 to verify that the account number is within a range of 
numbers associated with an issuer bank that is a PAS participant If the account 
number does not fall within a range of account numbers defined on the directory 
SGtvGT 128, then the issuer and thereby its cardholder are not registered with the PAS. 
In this case, the merchant is notified that the account number is not registered with 
1 0 PAS and the merchant plug-in software module returns control of the transaction back 
to the merchant storefiront software. At this point, the mCTchant storefix}nt software 
can proceed with the transaction, as it normally would, refuse fiirttier service to the 
cardholder, or proceed with alternative payment methods. 

On the other hand, if the account number is determined to be within a range of 
15 account numbers present in directory server 128, then the second st^ of the 
verification process begins. The second step of the verification begms by the 
directory sending the ACS capable of authenticating the cardholder the card number 
to detCTmine if the card is enrolled. If the card is not enrolled, the enrollment process 
is terminated. If the ACS indicates that the card is enrolled, the ACS via the directory 
20 server returns ite URL Internet address to the merchant plug-in. The mCTchant plug- 
in then invokes the ACS via the cardholder client device and it resident browser. 
Once again it is noted that thCTe can be multiple ACS's in PAS. 

A second method of checking to see if the cardholder is registered with PAS is 
for tibie merchant plug-in software module to directly queiy the ACS without first 
25 queryiag the directory server. The third method, as mentioned above, is for the 
merchant to have a cache memory containing the same information held at the 
directory server. IntiusmamiCT, the merchant can at least do a prelimiaaiy chec 

It should be noted that there could be more than one physical directory server 
in the PAS systCToi. However, it is preferable that there be only one logical directory 
30 server. In other words, all of the directory servers should be consistent in that they 
contain the same information. 
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If the cardholder is a PAS participant, the ACS displays a bank branded 
window to the cardholder. The bank branded window contains basic payment 
transaction information and prompts the cardholder for his PAS password. See FIG. 
5 for an -exemplary window 500 that prompts the cardholder for his or her PAS 
5 password. The cardholder enteis his or her password and the ACS verifies the 
password. As is common today, the cardholder can be given a certain nmnber of 
attempts to coirectly enter the password. If the cardholder is unable to correctly enter 
the password, then the cardholder can be prompted with the hint question that was 
estabhshed during the cardholder's registration process. Preferably, the cardholder is 
10 given one chance to enter the correct answer in response to the hint question. 

The payment authentication continues if the correct password is immediately 
entered or is the correct response is provided by the caxdholdCT to the hint question 
within the allowed number of attempts. The AGS then proceeds to digitally sign a 
receipt using the issuer's signature key or a service provider's key. This receipt will 

15 contain the inerchant name, card account number, payment amount, and the payment 
date. The receipt file 130 stores the following transaction data: merchant name, 
merchant URL, card accoimt number, expiration date, payment amount, payment 
date, the issuer paymCTt signature and the cardholder authentication verification 
value. The ACS then redirects the cardholder back to the merchant plug-in through 

20 the cardholder browser. At this point, the ACS also passes to the merchant the 
digitally signed recdpt and the determination as to whether the cardholder has been 
authenticated. The validation server 136, in the acquirer domain 106, is used by the 
. merchant plug-in 134, to verify the digital signatinre used to sign the payment receipt 
After verifying the digital signature, the cardholder is deemed "authenticated." In 

25 some embodiments of the invention, after the transaction is completed, the cardholder 
will also have the ability to re-register his or her card account and create a new 
password to be used for ftrture online purchases. 

After the cardholder is authenticated in step 3, step 4 initiates the process for 
authorizing the specific cardholder's account Specifically, in step 4, the merchant, 
30 througji the merchant plug-in software module, sends an authorization message to a 
paymait network such as VisaNet The payment network, in turn, forwards the 
authorization message and the ECI to an issuCT financial iiistitution. The 
authorization message is a message as is commonly known in the art The 
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authorization message is sent to the issuer so that the issuer financial institution can 
verify to ihe merchant that a specific account is in good standing and has adequate 
credit line for the requested purchase amount of the payment transaction. The ECI 
indicates that the transaction was completed over the Internet and indicates that level 
5 of message security (i.e., channel encryption (SSL), in the clear) and authentication 
used. 

In alternative embodiments of the invention, the merchant is enable of 
providing additional information along with the authorization message. For instance, 
the following information can also be sent: a flag indicating if the cardholder was 

10 successfiilly authenticated, account information, digital signatures, a cardholder 
verification value 2, card authentication verification value (CAW), an ofiQine PIN 
authenticated by chip card EMV cryptogram, and the necessary fields to provide the 
merchant with guaranteed payment. The CAW is data is created by the ACS which 
authenticated the cardholder and is a unique value for a given payment card and a 

15 specific payment transaction firom that card. It is used by PAS card issuers to 
uniquely identify authenticated payment transaction if any subsequent disputes occur. 
Afi:er die issuer financial institution processing of the authorization transaction is 
complete, control of the purchase transaction is then returned to the merchant's 
storefront software via the payment network. The issuer then returns the 

20 authorization response via the payment network to the merchant In step 5 of FIG. 4, 
Ihe issuer financial institution will either authorize or decline the transaction. In some 
embodim^cits, the authorization messages can be batched and sent in a groi^ at a later 
time. The PAS authentication information is also included in the batch, authorization 
messages. 

25 The access control server 114 is capable of various other functions. For 

example, the access control server can deactivate registCTed accounts firom the 
database. Accoimts can be deactivated manually, by the cardholder, or by the issuer. 
The access control server 114 can also provide a simplified renewal registration 
process when the cardholder receives a replacement card. The access control server 

30 114 can support multiple users of the same registered account with unique access 
control information. When providing a user with a connection to the access control 
server 1 14 for purchase transactions or account iq>dating, the access control server 
114 can validate the user as an authorized cardholder of the registered account 
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throu^ one or more of the following mechanisms: pass phrase, digital signatures, an 
online PIN number, or and off-line PIN authmtication by chip card EMV cryptogram. 

In the PAS, the merchant 132 can interoperate with existing systems where 
the merchant has the cardholder account information on file, interoperate with 
existing merchant authorization and clearing systems, support third parties who 
provide services to multiple merchants, support a variety of payment interfaces 
between the merchant and the acquirer, and minimize the mandatoiy impact to 
payment network authorization messages &om the acquirer when setting the value of 
the electronic commerce indicator (ECI). 

One method for routing transactions jQrom the merchant to an access control 
server is to have a directory that provides the address of tiie server based on the 
cardholder account number. Jn such a melhod, flie PAS requests for routing 
information is only acceptable from authenticated merchants. If PAS detects and 
reports activity from a merchant that exceeds its normal activity, then PAS is able to 
deny access to a merchant whose acquirer indicates that such access is no longer 
valid. This could be the case when merchant fraud is deemed probable. Merchant 
authentication to the PAS system can be deployed, but deployment is not required. 
Merchant authentication can help mioicoize merchant fraud. 

20 DETAILED MESSAGE FLOW FOR PAS PAYMENT TEIANSACTIONS 

FIG. 6 illustrates exemplary messages that are sent dining the payment 
transaction superimposed over the PAS architecture. As described above, the 
purchase transaction begins when a cardholder visits a merchant website via a 
browser and selects items to purchase. The merchant's payment system will ask the 

25 cardholder to enter his or her payment information. Generally, entry of the payment 
information should occxu* ia a secure environment, for example, through the use of 
SSL encryption protocol. When the cardholder indicates that he or she is ready to 
. finalize the transaction, the merchant's paymeut system invokes the PAS merchant 
plug-in soflware module 134. Then as shown by line la, the plug-in software module 

30 134 checks the directory server 128 for the ^ecific URL of the ACS that may contain 
the cardholder's Payer Authentication Number (PAN) to validate that the cardholder 
is enrolled in the service. Altematively, the plug-in software module 134 checks its 
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own cache memory that contains this information. The software 134 searches for the 
PAN by formatting a VeriJyEnrollmentReq message nsmg the cardholder PAN. If not 
already estabUshed, the merchant plug-in software 134 will estabHsh a secitre 
connection with and authenticate itself to the directory sCTver 128 or the access 
5 control server 1 14, The merchant plug-in software 1 14 will search for a card range 
entry that corresponds to the cardholder PAN at various locations. One place that is 
searched is the merchant plug-in software cache of directory information. The 
merchant plug-in software module can also check the directory server and the access 
control server. 

10 After ttie merchant plug-in software 114 conducts the search, the 

VeriJyEnrollmentReq message is transmitted to the access control server 114 either 
diirectly, as shown by hue lb, or after JBrst passing through the directory server 128, as 
shown by line la. When the VeriJyEnrollmentReq message is transmitted to the 
access control server 114 via the directory server 128, titie directory server 128 

15 searches for a record corresponding to tiie cardholder PAN contained in the 
VerifyEnrollmentReq message. On unsuccessftil match, &e directory server 128 will 
format a VeriJyEnrollmeritRes message with no URL value(s) and set the value of 
Status of PAN Enrollment or VeriJyEnfollmentRes-Status to •'N." The 
VeriJyEnrollmentRes message is then returned to the merchant plug-in software. On 

20 the other hand, upon succ^ftil match, the directory server 128 will, if not already 
established, establish a secure coimection with and authenticate itself to the access 
control SCTver URL. Then, the VeriJyEnrollmentReq message is forwarded to the 
access control server URL. If that URL is not available, the merchant plug-in should 
proceed to the next access control server URL value (if available), and allow for up to 

25 a maximum of up to five access control server URL's to be searched. Of course, the 
number of URL's attempted is variable. If unsuccessftil on all attempts, a 
VeriJyEnrollmentRes message is returned to the merchant plug-in with 
VeriJyEnrollmentRes-Status set to *^' to indicate to the merchant that the purchase 
transaction cannot be processed as a PAS transaction. 

30 After the VeriJyEnrollmentReq message is received by the access control 

server 114, the access control server accepts the cardholder PAN from the 
VeriJyEnrollmentReq message and validates it against the account holder file 118. 
The acc^s control server 1 14 then formats a VeriJyEnrollmentRes message. In the 
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case where a successful match occurs, the access control server sets the Status of PAN 
Enrollment to "Y," creates a single use proxy PAN, which the access control server 
114 will internally associate with the PAN, and populates the URL field(s) in the 
VerifyEnroUmentReq message. In the case of an unsuccessfW match, the access 
5 control server sets the Status of PAN Enrollment to 'TST." Then, as shown by Une 2a, 
the access control server returns a Veri/yEnrolbnentRes message back to the merchant 
plug-in through the directory server 128. For the case when a VenfyEnrollmentReq 
message is transmitted directly to the access control server, the VeHfyEnroUmentRes 
message is transmitted directly back to the merchant plug-in as shown in line 2b. 

10 Caching of the directory server 128 can be feciliated by utilizmg a CRReq 

and CRRes message pair. The CRReq message is sent from the merchant plug-in 
module to the directory server and requests the list of pdrticipatmg card ranges, in 
order for the plug-in module to update its cache. The CRRes message is the response 
containing the participating ranges. 

15 After the issuer access control server returns the VerifyETO-ollmentRes 

message, the PAS system checks to see if the cardholder cHent device has distributed 
authentication capabilities by using a QueryCardholderReq and QueryCardholderRes 
message pair. The merchant plug-in will format and send a query, the 
QueryCardholderReq message, to the cardholder client device 122 to determine if a 

20 distributed PAS cardholder module is resident Sending of the QueryCardholderReq 
message is shown in FIG. 6 by line 3. If any distributed authentication options are 
returned in the QueryCardholderRes. message, the merchant plug-in will 
communicate directly with the PAS cardholder client software to perform the 
authenticated steps. Sending of the QueryCardholderRes message is shown in FIG. 6 

25 bylme4. 

If die VertfyEnrollmentRes-Status has a value not equal to "Y," tiien the 
merchant is noti&ed that the purchase transaction cannot be processed as a PAS 
transaction. However, if the VeriJyEnroUmentRes-Status has a value of then the 
merchant plug-m will, format a payment request message, PARjeq. The merchant 
30 plug-in will send the PAReq message via the cardholder cUent device browser to the 
issuer's ACS server, as is shown by line 5, 
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Additionally, by using the QiieiyCardholderReq and QueryCardholderRes 
messages, the VerifyEnrollmeniReq and VmrftyEnrollmentRes messages may be 
eliminated. Cardholder client software could be d^loyed with issuer's ACS URL 
embedded in the software. The merchant plug-in will complete the 
5 QueryCardholderReq and QjueryCardholderRes messages first If PAS cardholder 
client software is detected, the Payer Authentication Request (P^eg) message could 
be sent to the ACS or tiie cardholder client software without having to conduct the 
VeriJyEnrottmentReq and VerifyEnrollmentRes messages. 

After the merchant plug-in passes the Payer Authentication Request (PAReq) 
10 to the issuer's ACS, the ASC displays a window to the cardholder. The window 
displa3^ the payment details contained in the Payer Authentication Response (PARes) 
in addition to other items such as: a Issuer's logo, a service organization maik or 
brand logo, merchant name, merchant location CURL)? total purchase amount and 
currency, purchase date, card number, installment/recurring payment terms, order 
15 description or link to description, special terms and conditions of sale or Imlr to this 
infozmation, personal assurance message (PAM), and prompt for the cardholder's 
password. 

The ACS will then prompt the cardholder to enter the qypxppriate password. 
The ACS accepts the cardholder iiq>ut and validates it against the accoimt holder jSle 

20 118. The PAS will allow, for example, a number of unsuccessful attempts (e.g., tiuree 
attempts) to eoAsir the correct password. Of course, the nmnber of attraipts allowed 
can be varied- AAct the final unsuccessful attempt, the PAS will display the hint 
question. The cardholder will need to enter the correct hint question response. The 
hint question associated with the cardholder is then displayed. The cardholder is 

25 provided at least one atternpt to enter flie correct response. If the cardholder provides 
an incorrect response, merchant can be notified that PAS transaction cannot be 
completed. If the cardholder provides the correct response, the transaction should be 
treated as if the password was matched. Note, if there is more than one entry for an 
accoimt number, the various cardholder names are displayed in a drop down window. 

30 The cardholder can then select his or her name. 

Upon matching of the password, , the ACS generates and digitally signs a 

payment response message, PARes. The ACS also generates and sends a SaveReceipt 

message to the receipt file 130 and receipt manager 131, as is shown by line 7, As 
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shown by line 7a, the SaveReceipt message may also be passed fix)m the receipt jBle 
130 to the issuers authorization and settlement system 138 to allow the issuer to 
match up the payment aufhorization request witii the payer authenticated transaction 
in real time. Sending the SaveReceipt message to the issuers authorization and 
5 settlement system 138 allows the issuer to determine simultaneously if the 
authorization request is for an authenticated purchase. The ACS will then re-direct 
the signed PARes back to the merchant server plug-in, as is shown by line 6. 

After signed PARes is transmitted back to the merchant plug-in, the plug-in is 
reactivated. If the authentication status is a the plug-in sends the PARes to the 

10 validation server 136. In the case that the validation server functions are provided by 
tiie merchant plug-in, the merchant plug-in validates the PARey signature and returns 
the result of the signature validation. If the signature cannot be validated, the 
merchant plug-in will notify the merchant the transaction cannot be treated as a PAS 
transaction. If the authentication status is a **N," the merchant should send a prompt 

15 to the cardholder asking for additional information, request the cardholder to use a 
different payment card or form of payment, or process the payment transaction as a 
non-authenticated payment transaction. 

In the case that the acquirer domain 106 contains a validation server, the 
validation server 136 validates the signature on the PARes. The validation server 136 

20 then returns the result of the signature validation to the merchant plug-in. If the 
signature cannot be validated, merchant plug-in notifies flie merchant that ttie 
transaction cannot be treated as a PAS transaction. On the other hand, if the signature 
is validated, the merchant proceeds with an authenticated payment authorization. The 
PARes message may also be passed from the merchant to its acquirer payment 

25 processor 140 as shown in line 6a. The PARes message may then be passed from the 
acquirer through a teleconmiunications network 142 to the issuer. Thus, the payer 
authentication results are made available to the issuer as part of the standard payment 
authorization process. 

Now the secmity issues related to the various channels of transmission will be 
30 discussed. As a base-line, all the channels of traiismission are preferably encrypted 
using 128-bit SSL. The channel between the cardholder and the merchant includes 
two channels. The merchant should secure the coimection that is used when the 
cardholder enters the payment information by using an SSL certificate obtained from 
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a service orgacdzation-^roved certificate authority. The merchant shoidd also 
secure the connection used to transport tihe PARes message fix>m the cardholder to the 
merchant plug-in by using an SSL certificate obtained firom a service orgamzation- 
qjproved certificate authority. 

5 The channel between the cardholder and the ACS should be encrypted by the 

ACS by using an SSL certificate obtained firom a service organization-approved 
certificate authority. This channel is used for two purposes. First to send the PAReq 
message firom the merchant plug-in to the ACS, and secondly to send the signed 
PARes message firom the ACS to the cardholder. 

10 The channel between the cardholder and the enrollment server should be 

encrypted by fiie enrollment server using an SSL certificate obtained fcora a service 
organizatidn-approved certificate authority. This channel is used to accept the 
cardholder enrollment information. 

The channel between the mCTchant and the directory server, and between the 
15 directory server and the ACS server should be secured through a service organization- 
issued SSL encryption certificate in order to protect the PAN data contained in the 
VerifyEnrollmentReq and VeriJyEnrollmentRes messages and the ACS URL address 
contained in the VeriJyEnrollmentRes message. 

The channel between the ACS to the cardholder should be encrypted to 
20 protect the prompt for the cardholder's password and the cardholder entered 
password. This channel should be protected with an SSL certificate obtained from a 
searvice organization-^)proved certificate authority. 

CENTRALIZED AND DISTRIBIJTED ARCHIT^ 

25 FIGS. 7 and 8 illustrate a centralized architecture and FIGS. 9 and 10 illustrate 

a distributed architecture. FIGS. 7-10 also show the superimposed representations of 
the message flows during both the enrollment and payment processes. 

FIG. 7 illustrates the message flows on the centrali2^d PAS architecture 
according to one embodiment of the present invention. As previously mentioned, the 
30 centralized approach requires no soflware or data to be stored on the cardholder's 
system and the cardholder's password is stored at a central data storage site (AHF). 
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The centralized architecture 700 consists of a cardholder client device, for sample, a 
personal computer (PC) 702, and the PAS 704. The cardholder client device 702 
supports an Internet browser 706 fliat allows the cardholder to access PAS. PAS 704 
includes at least an enrollment server 708. The various other cotx^onents of the PAS 
5 . system have not been illustrated so not to unnecessarily complicate the representation 
of the centralized architecture. The centralized enrollment process begins at step 1 
when the cardholder goes to the bank Internet site and the specific enrollment page to 
register with PAS. In response to the cardhold^ inquiry, in step 2, the enrollment 
server 708 presents the cardholder with authentication questions. In step 3, the 
10 cardholder answers the authentication questions and provides the required password. 

The em*ollment server then validates the answers through a vaUdation process 
in step 4. The result of the validation process is returned to the enrollment server 708 
in step 5. At step 6, databases and directory servers are updated. At step 7, the 
cardholder is informed whether or not his or her registration has been conjQimed. 

15 FIG. 8 illustrates the centralized pasonent flow that occurs between the 

cardholder client device 702, PAS 704, and the merchant system 720, according to 
one embodiment of the present iuvention. hi FIG. 8, PAS 704 is shown to include a 
dkectory server 710, the ACS server 712, and a receipt database 714. The merchant 
server includes a storefront software program 722, a PAS provided merchant plug-in 

20 software module 724, and a payment system 726. The c^tralized payment flow 
be^ns when the cardholder shops at the merchant's electronic commerce web site at 
step 1. When the cardholder begins the checkout process, step 2 shows that the 
merchant plug-in module 724 checks to see if the cardholder has been enrolled in the 
directory server 710. If the cardholder is enrolled, the directory server returns the 

25 URL address of the issuer's ACS server to the merchant plug-in. At step 3, the 
merchantplug-inmodule724sendsaP/lRe5messagetothe ACS 712. In response to 
the PAReq message, the cardholder eventually enters his or her password. Assuming 
the password is validated successfully by the ACS server, in step 4, a digitally signed 
PARes message is sent to the merchant plug-in module from the ACS 712 informing 

30 the merchant that the transaction is authenticated. The status of the transaction is sent 
to the payment system 726 in step 5. To conclude the transaction, in step 6, the 
merchant's storefront spftwiare 722 sends the payment data to the payment system. 
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FIG. 9 illustrates the enrollment flow in the distributed PAS architecture 
according to one embodiment of the present invention. As previously mentioned, the 
distributed architecture stores software and/or data on the cardholder's system. In the 
distributed approach, merchants determine a cardholder's participation in the PAS 
5 through a mechanism withm the PAS cardholder module on the cardholder client 
device. The distributed architecture 900 includes at least tiie cardholder client device 
902, which includes an Internet browser 904, and PAS 906, which includes an 
enrollment servCT 908. Note that in the distributed gqjproach, there is no directory 
server. The enrollment process begins when a cardholder goes to the bank specific 

10 Internet enroUment page to register with PAS in step 1. In step 2, the cardholder is 
presented with authentication questions. In step 3, the cardholder returns answers to 
the authentication questions to the enrolhnent server 908. The cardholders answers 
are validated in step 4 through a validation process. The results of the validation 
process are returned to the enrollment server 908 in step 5, If the cardholder is 

15 validated, then a cardholder software module 910 and a certificate are provided to the 
cardholder in step 6. These are down-loaded across the intemet firom the enrollment 
server. 

FIG, 10 illustrates the payment flow in the distributed PAS architecture 
according to one embodiment of the present invention. The merchant module 950 

20 includes the stoiefiont software 952, the merchant plug-in software module 954 and 
the payment system 956. The payment process begins, as usual, in step 1 when a 
cardholder shops and proceeds to checkout at a merchant's electronic commerce web 
site. In step 2 Ihe merchant checks to see if the cardholder software module 910 is 
present in the cardholder's client device. If ttie cardholder software module 910 is 

25 present, the mCTchant module 954 sends a PAReq message to the cardholder software 
rnodule 910, rather than an ACS as in the centralized architecture. The cardholder 
PAS software module, which knows the intemet URL address of its issuer's ACS 
setyer, passes on the PAReq message to the ACS server. The ACS server dialogs 
. with the cardhold^ module to ask the cardholder for his password. If the password 

30 . supplied by the cardholder compares equal to the password for the same cardholder 
on the AHF, the cardholder is authenticated. Then the ACS server responds with the 
PARes message to the merchant module in step 4. The status of the authentication 
process and the associated data is sent to the payment system 956 in stqp 5. A receipt 
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of the transactions is sent to the receipt database 960 in step 6. To conclude the 
transaction and the payment data are scat to the payment system from the storefront 
in step 7. 

5 camp CAIU3 EMBODIMENT 

A chip card embodiment of the Payer Authentication Service (PAS) involves 
a cardholder using an integrated circuit card (also known as a chip card or a smart 
card) and a chip card reader. The chip card embodiment adds another level of 
authentication in an online purchase transaction. Where ttie previously described 

10 PAS provides the abihty to authenticate the identity of the cardholder in an online 
purchase, the chip card embodiment of PAS also provides ttie ability to authenticate 
that the cardholder actually has possession of his or her chip card. There are a variety 
of methods that can be used to validate the authenticity of the chip card. One 
approach is to use a secret generated by the chip, which can then be validated by the 

15 issuer's ACS. 

The chip card embodiment can also use the PAS to authenticate the cardholder 
as described previously in this document in addition the authenticating the card. Two 
techniques may be used to provide the PAS password to the ACS. In a first 
technique, the chip card credit and debit application of the chip card prompts the 
20 cardholder to ^e in their PAS password. The caidholder enters in the jpassword in a 
similar way as described previously. The password is then forwarded to the ACS. 

In a second technique, the PAS password is automatically siq>plied to the ACS 
by the chip card. This technique uses passwords stored on the chip card to 
authenticate the cardholder in order to allow tiie cardholder to utilize the chip card. 

25 This approach uses an applet resident on the card referred to as the "Access" applet, 
because it provides uiiiveisal access to the card, and its resident applications, and can 
be used to authenticate a cardholder. The Ajccess ^let can also disable access to the 
applications on the card. Upon presentation of the single, universal "Access" 
password and auflientication of the cardholder, the Access applet then allows the 

3.0 cardholder to access to a variety of services or ^plications (e.g., access to an online 
banking site, access to an electronic bill payment service). For example, by 
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presentation of a single "Access" password, the applet ihea allows use of any stored 
passwords on the card. 

Generally, the set up procedures and the authentication process for the chip 
card embodiment are the same as for the traditional card embodiment. The 
5 differences between the chip card embodiment and the traditional chip card 
embodiment will be evident in the description that follows. 

The chip card embodiment of the PAS will be described relative to each of 
FIGS. lOA, 11, 12, 12A and 13. FIG. lOA illustrates one embodiment of the chq> 
card payer authorization service architectmre. FIG. 11 provides a general description 

10 of the PAS chip card and cardholder authentication in an authenticated payment 
transaction. FIG. 12 illustrates a combination of a system architecture layout along 
with si:^)^imposed process flows. FIG. 12A illustrates a more detailed flow of 
messages during a payment transaction using a payer authentication service with a 
chip card. Finally, FIG. 13 is used to illustrate a different CTibodiment of the chip 

15 card payer authentication system. Specifically, FIG. 13 illiistrates the chip card 
embodimrat with an added feature of the Access application that is used to control 
access to the various applications that may be on a chip card. 

FIG. lOA provides a high-level system architecture view of one embodiment 
of the chip card payer authorization service. As usual, the payment transaction begins 
.20 when the cardholder accesses a merchant's electronic commerce web site using a 
cardholder cUent device 122. The cardholder cUent device 122 is connected to the 
issuer access control server 114, which has a chip payer authentication ACS plug-in 
115. The issuer ACS 1 14 is connected to an account holder file 118, which is in turn 
coimected to a receipt file 130. The merchant 132 uses a merchant plug-in software 
25 module 134 to participate in the payer authentication service. The merchant 132 is 
coimected to the directory server 128, the vaHdation server 136, and the acquirer 
payment processor 182. The acquirer payment processor 182 is connected to the 
paynient network 1 26, which is in turn coimected to the issuer 1 80. 

FIG. 11 illustrates a flow chart that provides a general description of a 
30 payment transaction using the chip card system. The payment transaction begins at 
block 1100 when a cardholder shops at an online merchant web site and desires to 
conclude the shopping experience at the checkout web page. In block 1110, the PAS 
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verifies that the cardholder is a PAS registered particq)ant, for example, after the 
cardholder cUcks the "bxxy" button. Then in block 1 120, the merchant phig-in module 
sends a PAReq message to the associated access control server, which leads to block 
1 130 Where the access server via the PAS cardholder module in the cardholder client 
5 device verifies that the cardholder cHent device includes chip card reader. If the 
cardholder does not have a chip card reader, then the payment transaction is either 
ended or another payment method must be used. 

If the cardholder client device has a chip card reader, then in block 1 140 the 
consumer is directed to insert his or her chip card into the diip card reader. In block 
10 11 50, the cardholder module in the cardholder client device requests the chip card to 
generate a cryptogram based upon secret information contained in the chip card. 
Also, in block 1160, the cardholder is requested to enter his or her registered PAS 
password. In block 1170, the chip card generated cryptogram and the cardholder 
entered password are both sent to the ACS fear authentication. 

15 At block 1180, the ACS vaHdates the PAS password in methods similar to 

those d^CTibed for the non-chq) card PAS system described previously as in FIG. 4. 
The ACS also independently generates another copy of the cryptogram for this chip 
card using information in the various conq>onents of the ACS server - see FIG. 12. If 
the PAS password matches, then the identity of the cardholder is authenticated. At 

20 block 1190, if Ihe cryptograms generated by each the chip card and the ACS are 
matching, then it is verified that the actual chip card is being used by the cardholder. 
At blpdc 1 195, a paym^t response message is sent back by the ACS to the merchant 
plug-in soflware module. The payment response message contains a card 
authorization verification value (CAW), to inform the merchant that the cardholder 

25 has been auth^ticated and that the actual card is being used at the cardholder cUent 
device is the proper card. The purchase transaction then proceeds as was described 
previously. 

Now, FIG. 12 is presented to illustrate payment process flows that are 
siqjerimposed vpon a chip card systeni architecture according to one embodiment of 
30 the present invention. The chq> card authentication architecture 1500 involves the 
cardholder cUent device 1510, the issuer's ACS 1520, the cardholder 1530, the chip 
card 1540, and fhs requesting party 1550. The requesting party in the PAS 
environment is typically the merchant The cardholdea: client device 1510 mcludes a 
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display device 1512, terminal software 1514, PIN pad or key entry device 1516, and 
the card reader 1518. The card reader 1528 is the electromechanical device into 
which a chip card is inserted for use with a terminal ^pUcation, functionally 
eqixivalent to a Card Acceptance Device or InterFace Device (IFD in a physical point 
5 of sale environment). 

The ACS 1520 includes PAS au&entication software 1522, a hardware 
security module 1524, the cardholder database 1526, and system software 1528. The 
chip card 1540 includes a chip card credit and debit application 1542 such as the Visa 
Smart Debit Credit Application (VSDC), It should be appreciated that a general debit 
10 and credit appHcation can be utilized in situations where the VSDC application is 
mentioned in the present specification. 

The requesting party 1550 is the merchant associated with a particular 
pajmient transaction. The issuer server 1520 is the ACS operated by an issuer or a 
third party on behalf of an issuer enable of validating a ch^ card's cryptogram. It 
15 acts as the interface between the requesting party 1550 and the cardholder client 
device 1510. The cardholder client device 1510 is a system of components and 
software that acts as an interface among the cardholder 1530, the chip card 1540 and 
the issuer^s ACS 1520 such as a personal computer, a mobile phone, a settop box or 
any other device or collection of functionally conQ)arable components. 

20 The cardholder 1530 is a party who is usually in control of the cardholder 

client device 1510 and capable of performing functions like inserting a card, entering 
a iPIN or checking to see whether components of the cardholder client device 1510 are 
properly operational. Chip card 1540 is a payment card from an issuer that contains 
the chip card credit and debit application 1542, for example Visa Smart Debit Credit 

25 Application. 

Referring to the numbered circles in FIG. 12, which correspond to ordered 
process steps, the following is a brief scenario describing what happens during chip 
card payment authenticatioii processing. In step 1, a requesting party such as a 
merchant, detennines that chip card authentication is required and calls upon the 
30 issuer ACS to do it. 



30 



BNSCXX^ID: <WO. .018224eA2.l > 



wo 01/82246 



PCT/USOl/13382 



In Step 2, the issuer's ACS, having obtained the primary account number 
(PAN) for the card to be authenticated from the pay request message sends a message 
called the VSDC Authentication Request to the cardholder client device. 

In step 3, the cardholder client device^ actiog ia response to the request from 
5 the issuer's ACS attempts to authenticate the card. First it determines whether the 
necessary components are present and op^ational. Then, by putting a message on the 
display, the cardholder client device requests the cardholder to insert the chip card to 
be authenticated into the card reader. 

In step 4, the cardholder responds by inserting the chip card in the card reader 
10 which generates a message to the cardholder client device informing it the card has 
been inserted, or depmding xxpon how sophisticated the card reader is, the cardholder 
client device may need to poll the card reader using the path numbered 5 to det^nxdne 
whether it is now able to read the card. 

In step 5, the cardholder client device initializes the chip card and the VSDC 
15 application on the chip card and then conmiimicates with them to direct the return of 
a cryptogram from the chip card for later validation. 

In step 6, in the course of communicating with the chip card several 
exchanges occur. The chip card may request that the cardholder to enter a PIN. If so 
then tiie cardholder client device notifies the cardholder to enter a PIN via a PIN pad 
20 or other key entry device. 

In step 7, while sending messages (cormnands) and receiving responses from 
the card in steps 5 and 6, the cardholder client device was gathering the information 
necessary to compose the VSDC Authentication Response which it now sends to the 
issue's ACS. The Access Control server using information provided in the VSDC 
25 Authentication Response message atterupts to autheoiticate both the cardholder via his 
password and the chip card yia its cryptogram. 

In step 8, the issuer's ACS replies via a pa3anent response message to the 
merchant or requesting party with the results of the cardholder and cMp card 
authentication processes. 

30 The principal functional capabilities of each entity in the VSDC 

Authentication service will now be described. The requesting party or merchant 
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fimctions to signal or trigger the issuer*s ACS to initiate chip card VSDC 
Authentication processing, provide issuer ACS with the necessary data to perform 
VSDC Authentication, and uses the result of VSDC Authentication provided by 
issuer's ACS. 

5 The issuer's ACS functions to securely store cryptographic keys needed for 

cryptogram validation, collect the necessary data to perform VSDC Authmtication 
processing, initiate VSDC Authentication processing by sending VSDC 
Authentication Request message to cardholder client device software, validate 
cryptogram sent from the chip card via the cardholder client device in its attached 
10 Hardware Security Module (HSM), and provide the result of the validation of 
cryptogram to requesting party or merchant via the payment response message. 

The cardholder client device functions to conomunicate with issuer ACS, 
receive VSDC Authentication Request message, communicate with cardholder for 
card insertion/removal and PIN entry, comnaunicate with the chip card, send 
15 necessary data for VSDC Authentication to chip card, receive necessary data for 
VSDC Authentication from chip card, receive cryptogram from chip card, and send 
the card generated cryptogram to the issuer ACS. The cardholder client device also 
requests the cardholder to enter his password and passes the entered password to the 
ACS. 

20 The cardholder functions to insert chip card into card reader, determine 

whether the chip card environment is ready, enter PIN, remove chip card from card 
reader, and ent^ his or her password. 

DETAILED MESSAGE FLOW EXAMPLE 

25 FIG. 12A illustrates a detailed flow of messages between the chip card 1540, 

the cardholder client system 1510, and the issuer's access control server 1520. This 
flow of message defines the manner in which chip card payment authentication 
processing is performed. The flow of messages is organized in a top-down manner 
that progresses through the phases of the authentication process. 

30 

Explanation of Message Flow 
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This section briefly describes the phases of the VSDC Authentication 
processing in the order in which they occur as illustrated in the preceding diagram: 

4^.1.1 VSDC Authentication Request - The issuer's ACS starts the VSDC 
Authentication processing. 

5 4.3.2.1 Initiation - The cardholder client device software pron^ts the cardholder to 

. . - .- • • • 

insert the chip card iuto the card reader. 

4.3.2.2 Application Selection - The cardholder client device software selects a VSDC 
appUcation firom the chip card. 

4.3.2.3 Application Initiation - The cardholder cUent system device and the chip card 

1, t,^. . ip._ Jm : , 

*' ' ■ ■ ' ' * .. "■ . - . , ^ 

43, 2 A Read AppUcation Data - The cardholder cUent system device reads the 
appUcation data from the chip card. 

4.3.2.5 Cardholder Verification (Optional) - The cardholder cUent device software 
performs ofOine PIN verification to authenticate cardholder. 

15 4.3.2.6 Temiinal Action Analysis - The cardholder cUent system device requests the 
chip card to graerate the cryptogram. 

4.3.2.7 Completion - The cardholder cUent device software completes and terminates 
the processing for VSDC AuthenticatiotL 

4.2.1.2 VSDC Autiientication Respoiise - The cardholder cUent device software 
20 returns the cryptogram and the other data to the issuer's ACS server. 

Now the message flow and the functions involved in generating the flow 
between the cardholder cUent device software and the chip card will be described. 
VSDC Authentication Request is the message that deUvers the necessary data firom 
25 the issuer access control server to the cardholder cUent device software to invoke the 
^ " " ~ cardholder cUent device sof^are to start processing. VSDC Auttientication response 

is tiie message that returns the cryptogram and the supporting data firom the 
cardholder cUent device software to the issuer's ACS. 

•-^ - * ' - • . - 

30 Now, the details of message and processing flow will be described: 
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VSDC Authentication Request is the message that invokes the cardholder 
client device software to start VSDC Authentication processing. This message 
contains the necessary data for the chip card to generate a cryptogram. 

The issuer's ACS preferably should obtain or generate the necessary data 
5 listed here: Amount, Authorized; Apphcation Identifier; Application Label (of 
VSDC application); Apphcation Preferred Name; Terminal Cpimtty Code; 
Transaction Currency Code; Transaction Date; Transaction Type; and Unpredictable 
Number. 

The source of these data varies dependent on the authentication environment 
10 within which VSDC Authentication is working. The issuer's ACS preferably should 
construct a VSDC Authentication Request to dehver these data to flie 'cardholder 
cUent device software. This message preferably should invoke the cardhdld^ client 
device software to start the processing between the cardholder client device software 
and the chip card. 

15 The cardholder chent device software preferably should start the initiation 

process. 

4.2.1.2. VSDC AUTHENTICATION RESPONSE 

VSDC Authentication Response is the message that deUvers the cryptogram 
20 and the other supporting data to the issuer' ACS server. VSDC Authentication 
Response message is also used to deUver the status code when errors and exceptions 
occur during VSDC Authentication pxocessiDg. The VSDC Authentication Response 
message is also used to provide the access control server with the cardholder's 
password. 

25 The cardholder client device software preferably should obtain aU the 

necessary data described in the table 1 below. 



Data Element 


Source ' 


Cryptogram 


From the first GENERATE AC response 
message. 


Derivation Key Index 
(DKI) 


Froih the first GENERATE AC rehouse 
message. 

(DKI is a component of issuer Application 
Data.) 
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Cryptogram Version 
Number 


From the first GENERATE AC response 
message. 

(Cryptogram Version Number is a 

conq>onent of 

issuer Application Data.) 


Application Xnt^change 
Profile (AIP) 


From the GET PROCESSESTG OPTIONS 

response 

message. 


Application Transaction 
Coxmter(ATC) 


From the first GENERATE AC response 
message. 


Card Verification Resnlts 
(CVR) 

. .. .. .... . 


From the first GENERATE AC response 
message. 

(CVR is a component of issuer .Application 
Data.) 


Terminal Verification 
Results (TVR) 


From the cardholder client device software. 


PAN Sequence Numbra- 


From the READ RECORD response 
message. 


Status Code 


From the cardholder client device software. 


Reserved for future use 1 


Filled by "00000000000000000000" 


Reserved for future use 2 


Undefined format and content, 10 bytes. 



Table 1 



The cardholder client device software preferably should construct a VSDC 
Authentication Response message to deMver these data to the issuer's ACS server. 



The issuer's ACS server preferably should retrieve the data firom the VSDC 
Authentication Response and validate both the cryptogram and the cardholder's 
. password. The issuer's ACS server receives the VSDC Authentication Response 
containing status codes when errors or exceptions occ\ir and when processing 
completes successfully between the cardholder client device software and the chip 
card. The issuer's ACS server may store the data fi*om the cardholder client device 
software to permit the issuer to use that information to analyze the processing that 
occurred between the chip card and the cardholder cli^t device software and to 
respond to inquiries fiom cardholders when errors and exception occm^. 
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Optional process at issuer ACS - If the authentication environment requests, 
the issuer ACS naay need to send the result of the authentication to the merchant or 
requesting party. In some environments, the issuer ACS may send an mdication that a 
cryptogram authentication has occurred and whether it was successful. Note: The 
5 VSDC Authentication Response is always sent even if the cardholder client device 
software terminates prematurely due to errors or other causes. 

The description will now cover the message flow and the functions involved 
in generating the flow between the VSDC application on the chip card and the 
10 cardholder client device software. First, an overview of processing flow of 
cardholder client device software fimctions to the chip card message flow is provided. 
The fimctions are those of initiation, application selection, application initiation, read 
application data, cardhold^ verification, termianl action analysis, and completion. 

Initiation describes how the cardholder cUent device software assures that the 
15 . chip card is inserted into the card reader and is ready for the process. Application 
Selection describes how the cardholder client device software proceeds to select 
VSDC application on the chip card for VSDC Authentication processing. 
Application Initiation describes how the cardholder client device software initiates the 
VSDC application on the chip card. Read Application Data describes how the 
20 cardholder client device software reads the VSDC ^plication data from the chip 
card. Cardholder Verification describes how the cardholder client device software 
performs cardholder verification. Terminal Action Analysis describes how the 
cardholder client dcAdce software requests the chip card to generate the Cryptogram. 
Completion describes how the cardholder client device software terminates the chip 
25 card processing and ends its processing. 

A detailed explanation of each flow and message will now be given. 

43.2.1. INITIATION - The Initiation phase comprises two sub-phases. One is 
Initiation for the card environment on the cardholder client device and the other is 
Initiation for the chip card. 

30 The cardholder cUent device software preferably should assure to the extent 

possible in the environment tiiat the card reader and any associated device siq>port 
software necessary to enable it are ready for card insertion. If the card environment is 
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not ready, the cardholder client device software preferably should commiinicate wiHi 
Cardholder to verify that conditions at the cardholder client device are correctly set 
up. Communication with the cardholder might include asking such questions as 
whether the card reader is properly attached, whether the power is on, and whether 
5 the correct version of card reader driver software is installed. The. cardholder client 
device software may terminate the VSDC Authentication processing if it determines 
that the card environment cannot be made ready. When the cardholder client device 
software terminates processing it preferably should skq> all succeeding phases and 
return the VSDC Autlicntication Response message to the .issu^ Service with an 
10 appropriate status code. 

. . If the sub-phase "4,3.2.1.2 Initiation for the chip card" fails, control may 

return to this sub-phase wliereupon the cardholder client device software prompts the 
cardholder to insert the chip card. The cardholder client device software may 
terminate VSDC Authentication processing if, after it requests card insertion and 

15 returns again to *Tnitiation for the chip card", the chip card subsequeiitly fails to 
respond. When the cardholder cUent device software terminates VSDC 
Authentication processing, it preferably should skip all the succeeding phases and 
preferably should send the VSDC Authentication Response message to the issuer 
ACS with an appropriate status code. 

20 Initiation for the chip card - In this sub-processing phase the cardholder ctient 

device software communicates with the chip card to determine whether it is ready for 
processing. 

The cardholder client device software preferably should reset the chip card. 
The chip card returns an Answer To Reset (ATR) to the cardholder client device 
25 software, or the chip card fails to return an ATR. 

When the cardholder client device software receives ATR, it proceeds to the 
next phase. Application Selection. When the chip card does not return ATR within a 
time established by standards, the cardholder client device software may return to 
"4.3.2.1.1 Initiation for card environment on cardholder client device" or it may 
30 tenninate VSDC Authenticia.tion processing. When the cardholder client device 
software terminates VSDC Authentication processing, it preferably should skip all the 
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succeeding phases aad preferably should send the VSDC Authentication Response 
message to the issuer server with an appropriate status code. 

4.3.2.2. APPLICATION SELECTION 

S Application Selection is the processing phase in which the cardholder client 

device software selects the VSDC q>plication from the chip card. 

Process at Ihe cardholder client device software includes the following: 

(a) The cardholder client device software preferably should perform 
Application SelectioiL 

10 (b) To comply with security requirements, cardholder client device software 

preferably should use only the £?qplicit Selection Method, sending the SELECT 
commands with the ADD (Application ID) as supplied in the VSDC Authentication 
Request. 

(c) If the response to the first SELECT command returns an AID with no 
15 suffix^ then there is only one instance of theapplication for the requested AID on the 

card. Processing continues with step g)below. 

(d) If the response to the first SELECT conimand returned an AID with a 
sufOx indicating there are multiple instances of the application for the requested AID 
on the card then processing continues with step e) through step g) below, 

20 (e) By issuing successive SELECT commands using the AID (as supplied in 

the VSDC Authentication Request) imtil the card indicate there are no additional 
instances of apphcations for the requested AID to be returned. As each AID is 
returned the cardholder client device software constructs a list of AIDs along with the 
corresponding AppUcation Label and Application Preferred Name for each AID. 

25 (f) Using the Application Label and the Application Preferred Name as 

supplied in the VSDC Authentication Request the cardhplder client device software 
searches the list constmcted in the prior step for a match. The SELECT command is 
issued to the card using the AID of the matched Ust entry. If no rnatch is founds the 
appropriate status code is set for return in the VSDC Authentication Response as 

30 indicated in **Exception handling*' below. 
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(g) Application Selection for the cardholder client device software is 
complete. Either fliere was a singular eligible ^plication on the card and it was 
selected in step c) above. Or, it has been determined among multiple eligible 
^plications which one to select in step f) above. 

(h) When the cardholder client device software and the chip card support 
multiple ^plications in addition to VSDC, it is the issuer's responsibihty to decide 
which and in what sequence other applications are to be executed. 

The chip card performs Application Selection. 

Exception handling - If the VSDC application is not found, the cardbolder 
client device software preferably should terminate VSDC Autiientication processing. 
Whm the cardholder client device software terminates VSDC Authentication 
processing, it preferably should skip aU the succeeding phases and preferably should 
send VSDC Authentication Response to the issuer server wifli an appropriate status 
code. 

4.3.2.3. APPLICATION INITIATION 

Application Initiation is the processing phase during which the cardholder 
client device software signals to the chip card that transaction processing is 
beginning. 

The cardholder client device software preferably should initiate the 
application. The cardholder client device software preferably should send the GET 
PROCESSING OPTIONS command to chip card to initiate the VSDC plication. 

The chip card responds to the GET PROCESSING OPTIONS command. 

The cardholder client device software preferably should store the Application 
Literchange Profile that will be used in later phases to construct the VSDC 
Authentication Response. Enforcing geographical restrictions is one of the optional 
functions of the VSDC application. 

When the chip card responds to the GET PROCESSING OPTIONS command 
with an error code that indicates the conditions of use are not satisfied, the VSDC 
Authentication proc^sing must be terminated. 
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If the card terminates the transaction then the cardholder client software 
device preferably should skip all the succeeding phases and preferably should s^d 
the VSDC Authentication Response message to tile issuer server with an ^propriate 
status code. Note: It is the issuer's responsibility to decide what action to take after 
5 termination of VSDC Authentication processing. Such decisions and consequent 
actions are outside the scope of this document. 

4.3.2.4. READ APPLICATION DATA - Read Application Data is the processing 
phase in which the cardholder client device software reads the records of VSDC 
10 application files on the chip card. 

The cardholder clicnl device software preferably should read the VSDC 
application data. The cardholder client device software preferably should sends 
READ RECORD commands to retrieve the necessary data from the VSDC 
appUcatLon. The cardholder client device software preferably should retain the value 
15 of the PAN Sequence Number for later use in composing the VSDC Authentication 
Response. 

The VSDC application responds to the READ RECORD commands. 



4.3.2.5. CARDHOLDER VERIFICATION - Cardholder Verification is the phase of 
20 processing in which the cardholder chent device software may verify the cardholder 
by using an offline PIN verification method. Note: Cardholder Verification must be 
implemented in corpphance with appropriate Visa security guidelines. 

Conditions of execution - This phase is conditional, i.e. required only when 
cardholder Verification is implemented and available on the card and in the 
25 cardholder client device software. 

The cardholder client device software preferably should verify the cardholder 
using the Offline Plaintext PIN Verification method. Neither the Offline Enciphered 
PIN Verification method or Online PIN verification is supported. 

The chip card performs Offline Plaintext PIN Verification. In response to the 
30 first GENERATE AC command, the chip card provides the result of the ofiEline PDST 
verification in the CVR. 
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4.3.2,6. TERMINAL ACTION ANALYSIS - Terminal Action Analysis is the phase 
of processing in which the cardholder cUent device software requests the chip card to 
generate a Cryptogram, which will be sent to the issuer server for validation. 

5 The cardholder client device software preferably should perform Terminal 

Action Analysis. The cardholder client device software preferably should assume the 
role of the "merchant POS teraiinal" described therein and behave just like that 
terminal with the following exceptions: 

a) Issuer Action Code and Terminal Action Code Processing: The cardholder 
client device software preferably should not compare the Terminal Verification 
Results to the chip card's issuer Action Codes or to Terminal Action Codes. 

b) GENERATE AC Command: The cardholder cUent device software 
preferably should construct the GENERATE AC comniaud by requesting only 
ARQC, i.e., must not request AAC or TC during Teraunal Action Analysis. 

Terminal Verification Results (TVR) values - Tenninal Verification Results is 
a record of the outcome of the various application fimctions performed by the 
cardholder client device. Different fi-om the standard VSDC processing at POS 
terminal, some of the values are static for VSDC authentication. The values to be 
assigned to bits tha:t are static are indicated below. Bits whose values are to be 
dynamically set, will be set by the cardholder client device during the course of the 
VSDC Authentication processing. 

The chip card produces a oyptogram. 

4.3.2.7. COMPLETION - Completion is the processing phase in which the 
cardholder client device software temiinates the processing of the chip card. 

Process variation - The cardholder client device software processing 

preferably should vary based upon the GENERATE AC response message. The 

cardholder client device software preferably should perform Completion, The VSDC 

application provides the chip card with the authority to decline transactions offline 

(AAC) even if the cardholder client device software issues the first GENERATE AC 
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coimnand for an online authorization (ARQC). Therefore the client catdholder device 
software should e^ect that the chip card will return either an ARQC or AAC during 
VSDC Authentication processing. To determine whether the outcome of the 
GENERATE AC is an ARQC or AAC the issuer ACS can check the CVR. 

5 VSDC Authentication preferably should continue processing even though the 

response from the chip card is OfiEline Decline (AAC). Processing can continue 
because even though tiie response indicates declined, the retumed cryptogram can 
nonetheless be used for card authenticatioiL VSDC Authentication requires the 
cryptogram for card authentication regardless of the type of the oyptogram. 

10 4.3^.7- 1 . Card response is ARQC 

This sub-section describes the processing flow when the chip card returns an 
Authorization ReQuest Cryptogram (ARQC). For VSDC Authentication, such an 
interpretation is not relevant because an authorization will not be requested and 
VSDC Authentication is always an "online" process. The objective of issuing the 
15 GENERATE AC command is to cause the card to return a cryptogram for vahdation. 

After receiving the first GENERATE AC response with ARQC from the chip 
card, the cardholder client device software pref^ably should perform the following: 

The cardholder cKent device software preferably should keep only the 
cryptogjram and no other data except for the following data elCTients sent from the 
20 chip card in order to send them to the issuer server; see Table 2. 



Data 


Element Source 


Cryptogram 


From the jBrst GENERATE AC response 
message. 


Derivation Key Lidex 
(DKI) 


From the first GENERATE AC response 
message. (DKI is a component of issuer 
AppUcation Data.) 


Cryptogram Version 
Number 


From the first GENERATE AC response 
message. 

Cryptogram Version Nuinber is a 
component of issuer 
Application Data. 


Application Transaction 
CountCT (ATC) 


Froin the Grst GENEELATE AC response 
message. 


Card Verification Results 
(CVR) 


From the Gist GENERATE AC response 
message. 

(CVR is a component of issuer Application 
Data-) 
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Table 2 



The cardholder client device software preferably should store information 
necessary for subsequent phases to prepare dnd send the' VSDC Authentication 
5 Response. Then, the cardholder client device software preferably should issue the 
final GENERATE AC command to the chip card as if the online authorization 
response would indicate transaction unapproved by the issuer. It means that the 
cardholder client device software requests an AAC. Note: There are no authorization 
request/response messages in VSDC Authentication processing. 

10 

Source of data listed in CDOL2 - The Data Elements, which ttie cardholder 
client device software transtnits to the chip card iii the data field of the final 
GENERATE AC command, preferably should foe obtained firom the sources indicated 
in the table 3 below. 



Data Element 


Source 


Amount, Authorised 


From Network-based VSDC 
Authentication Request 
message 


Amount, Other 


From Network-based VSDC 
Authentication Request 
message ^ 


Termirial Country Code 


From Network-based VSDC 
Authentication Request 
message 


Terminal Verification 
Results (TVR) 


From ^6 cardholder ch&nt device software 


Transaction Currency 
Code 


From Network-based VSDC 
Authentication Request message 


Transaction Date 


From Network-based VSDC 
Auflienticatipn Request message 


Transaction Type 


From Netwoit-based VSDC 
Authentication Request message 


Unpredictable NinnbCT 


FroniNetworkrbased VSDC 
Authentication Request 
message 



15 Tables 
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The chip card returns the response to the fin£d GENERATE AC command 
withAAC 

The cardholder client device software preferably should ignore a response 
from the chip card to the final GENERATE AC command. The cardholder client 
5 device software preferably should comply with security requirCTaents by clearing 
from its memory extraneous data recdved from the chip card. Note: It is assumed 
that by this time all prior unus^ data from previous phases have been cleared in 
compliance with security requirements. 

10 Card response is AAC 

This sub-section describes the processing flow when the chip card returns an 
AppUcation Authentication Cryptogram (AAC). For VSDC Authentication, such an 
interpretation is not relevant because an authorization was not requested. The 
objective of issuing the GENERATE AC command is to cause the card to retum a 
1 5 cryptogram for authentication of the chip card. 

After receiving the AAC in the response to the first GENERATE AC 
command from the chip card, the cardholder client device software preferably should 
perform the following fimctions. The cardholder cUent device software preferably 
should keep the cryptogram and the other information sent firom the chip card in order 
20 to send them to the issuer ACS. The cardholder cUent device software preferably 
should pr^are to send VSDC Authentication Response. The cardholder cUent device 
software preferably should clear all the data received fix>m the chip card in all phases. 

CHIP CARD EMBODIMENT WITH ACCESS APPLICATION 

25 Now that the description of the message flows in FIG. 12A has been 

completed, enibodimrat of the chip card device utilizing an Access application wiU 
now be presented. 

The additional embodiment of the chip card system involves an Access 
application that can optionally be used as an extra feature of the chip card system. 
30 The Access application is used to control access to the chip card and the multiple 
^plications that may reside on the chq> card. The Access application can be referred 
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to as the '"Access application or applet." The Access application controls access to 
the other ^plications resident upon the chip card. In this manner, the Access 
application is able to verify tibe identity of the person attempting to utilize the chip 
card and its associated ^plications. If the person attempting to xise the chip card 
5 enters the correct user identification number or string, and a password, then it is 
presumed that an authorized person is about to use the chip card. In this case, the 
Access appUcation unlocks all of the applications on the chip card so that they may be 
used. In addition to imlocking the 2^pUcations, the Access application can make the 
passwords for the apphcations on the chip card available for use. In some 
10 embodiments of the Access application, only a select ninnber of the applications will 
be unlocked after entering the correct information in response to the Access 
application. 

There are numerous references to the passwords or secret values that the 
cardholder enters and/or the issuer ACS checks. As shown in Table 4, secrets #1, #2, 
1 5 and #3 are dijSerent values (and none of the three is a financial ATM or POS PIN). 

Secret #1 A cardholder-defined password to enable access to the chip card Access application 
for chip-based payer authmtication. In some embodiments, secret #1 allows an access 
program on a smart card to open aU the applications on a smart card, including the PAS 

application, 

Secret #2 An issuer-defined password returned by the chip card Access application to enable 
the ACS to validate the cardholder for chip-based payer authentication. The cardholder is not 
required to know this password since it is automatically used to open applications on the smart 

card. ■ - ■• 

Secret #3: The password used in the non-chip card embodiment of PAS (the core system). 
The cardholder-defi^ied password to enable the ACS to vaUdate the cardholder. This 
password or secret can also be used to validate the cardholder wh^ chip card access is not 

available on the card. 

Table 4: Passwords and Secret Values 



FIG* 13 illustrates a system diagram of the components utilized in the payer 
20 authentication service using the chip card and a universal .Access appUcation. The 
system diagram of FIG. 13 shows the chip card 1540, the chip card reader 1518, the 
cardholder cUent device 122^ the access control server 114» and a database 1240. The 
chip card 1540 includes the access ^)plet 1202 and the chip card credit and debit 
appUcation 1204. The access ^iplet 1202 stores a password, which is secret #2, that 
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will be used to imlock the various applications on the chip card. The cardholder client 
device includes the payer authentication application 1542. 

Upon making an online purchase transaction, the access applet 1202 prompts 
the cardholder to enter his or her user ID and password, which is secret #1. If the 
5 cardholder enters the correct user ID and the associated password, then secret #2 is 
automatically used to unlock the applications on the chip card. Then the PAS system 
utilizmg the chip card system can proceed as was described earlier in this 
specification. 

This second, more detailed description explains the processes and coimnands 
10 that should be supported by the cardholder cUent device software, which facilitates 
communication between the chip card reader, the cardholder's Internet browser and 
the ACS. 

The various basic processes and commaiids will now be described. First, the 
cardholder client device software will be activated by a message firom the ACS server 

15 (cUent can also be implemented with a timeout feature, e.g. a client will be tinied out 
after 30 minutes). Then, the cardholder client device software will check for the 
existence of a compliant chip reader and re^ond to the ACS that it is capable of 
processiDg a chip based payer authentication transaction. The cardholder cli^t 
device software will receive a message ftom the ACS containing the ^propriate 

20 inerchant and ACS data to enable a chip card program (e,g., VSDC ^plication) to 
generate a cryptogram. An example of such a chip card program is the Visa Smart 
Debit Credit application (VSDC), which is Visa's implementation of the Europay, 
Mastercard, and Visa (EMV) chip card standard. The cryptogram is a cxcyptogr^hic 
value generated by the card that is specific to the card and to ekch transaction. The 

25 ACS can validate that the cryptogram using cryptogr^hic in hardware security 
module. It is noted that the VSDC application is the same ^yplication used in the 
faqe-to-face transaction taking place at brick-and-mortar POS merchant 

After receiving the message from the ACS, the cardholder client device 
software will check for the presence of secret #2 and UID in the defined data element. 
30 If it is not available, the cardholder client device software will ask the cardholder to 
insert the chip card and enter secret #1 to validate against the chip card Access 
appUcation and retrieve secret #2 and User ID (UID). 
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If the. cardholder is validated for chip-based payer authenticatioii, the 
cardholder client device software will execute a VSDC purchase transaction to obtain 
the cryptogram and associated data to perfoim Online chip card Authentication. 

Execution of the VSDC purchase transaction involves multiple steps to be 
5 taken by each of the cardholder client device software and the VSDC chip 
appUcation. The cardholder chent device software will perfomi AppUcation 
Selection using the ExpUcit Selection Method by issuing one or more SELECT 
commands to the card. The cardholder cUent device software will also issue a GET 
PROCESSING OPTIONS command that includes the PDOL, if a PDOL was present 
10. in the File Control Information (FCI) from Application Selection. Then the VSDC 
chip appUcation will return the Application File Locator (AFL) and Application 
Interchange Profile (ADP) in the response from the GET PROCESSING OPTIONS 
command. 

The cardholder chent device software will issue the READ RECORD 

15 commands necessary to read the VSDC chip appUcation records designated by the 
AFL. Note: The chip will return all of the data necessary to complete a VSDC 
purchase transaction, as well as the data used for intemet payment authentication. The 
cardholder. cUent device software wiU need to parse out the correct data. The 
cardholder cUeat, device software wiU then perfbnn the Processing Restrictions 

20 checks, bypass CVM List Processing, and bypass Terminal Risk Management except 
for the Floor Limit and New card checks. All transactions wiU be over tiie floor limit 
- . The cardholder cUent device software will set the TVR Transaction Exceeds Floor 
Limit bit to *1 The cardholder cUent device software will perform Temiinal Action 
Analysis and always request an ARQC (online) cryptogram in the GENERATE AC 

25 command. This command will include the CDOLl data including Transaction Date 
and the Unpredictable Nimiber from the ACS. Then the cardholder cUent device 
software will pass the cryptogram returned by the chip and supporting data imaltered 
to the ACS for vaUdation. Finally, the cardholder client device software will issue a 
GENERATE AC command requesting an AAC. This will teraiinate the transaction 

30 on the VSDC card application. After issuing the second GENERATE AC coramand, 
all infomiation from the transaction should be forgottra. by the cardholder chent 
device software 
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The following process occurs after the Merchant Plug In forwards the PAReq 
noiessage to the ACS. First, the ACS should determine if the cardholder's PC is chip- 
enabled. (Note: Though the PAN may be registered as being chip-enabled, this step is 
necessaiy in those situations where the PC currently being used in the transaction 
5 does not have a chip reader or is otherwise not chip-enabled.) The ACS should allow 
the issuer to configure two differmt actions for the situation whm the PC is not chip 
enabled or the chip is not readable. 

Option #1, prompt the cardholder for searet #3 (his or her PAS password). 
Option #2, do not perform any cardholder nor chip card authentication and populate 
10 the PARes Transaction Status jBeld with a **not applicable" response. The ACS 
should extract all of the appropriate merchant information from the PAReq and 
provide this data and the appropriate ACS information to the cardholder client device 
software that will be required to request the chip card to generate a cryptogram. 

The ACS then sends the information to support the cryptogram to the 
15 cardhold^'s cardholder client device software and sends a request for secret #2 and 
flie Unique Identifier (UID). The cardholder client device software invokes an 
application that obtains secret #2 (password) and UID fi*om the previously performed 
chip-enabled check-out process. If secret #2 is not available via this procedm-e, the 
cardholder client device software obtains secret #2 from the chip card by invoking the 
20 Access applet, which requires the cardholder to enter secret #1 to activate the applet, 
and obtains secret #2 and UID from within the Access applet on the chip card. If the 
Access applet is not present on the chip card. The cardholder client device software 
asks the cardholder to enter secret #3 (his or her PAS password). 

After secret #2 and UID are obtained, the cardholder client device software 
25 initiates a VSDC transaction to g^erate a cryptogram request and obtain the 
cryptogram from the chip card. If secret #2 is not obtained (i.e. the cardholder is not 
validated);, the cardhold^ client device software does not call upon the VSDC applet 

The cardholder client device software returns secret #2, the cryptogram^ and 
the supporting data to the ACS for the ACS to validate the cryptogram to the ACS. 
30 The ACS accepts the cardholder client device software's input and validates it against 
the Account Holder Database. If there is more than one Accovmt Holder Database 
entry (secret #2) for a Primary Accoimt Number (PAN), the cardholder is validated if 
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any of the entries (secret #2) match tiie secret #2 sent to the ACS by the cardholder 
cUent device software. 

The ACS validates the card by replicating the cryptogram and comparing it to 
the cryptogram from the chip card sent to the ACS by the cardholder client device 
5 software. The ACS creates the PARes message, populating all of the, and returns the 
PARes message to the merchant via the connection through the cardholder's browsCT. 

The ACS digitally signs the PARes, sets the PARes Transaction Status, 
Transaction Detail, ECI, values, chip card codes indicating the type of card, payment 
conditions, and card authentication results, and sends the signed PARes back to the 
merchant, and generates a SaveReceipt messsigG to the receipt manager 131 (the 
SaveReceipt message may also be refeired to as the PATrans message). 

Two types of chip cards carry the Visa Smart Debit/Credit (VSDC) 
application. First is a card that is capable of validating the cardholder 0>ayer) o£Eline 
via the Access application on the card using the access password or secret #1. The 
access password is obtained from the cardholder and passed to the cardholder client 
device software on the browser. If the access password provided is correct, the chip 
card Access ^plication returns secret #2 and UID to the cardhold^ client device 
software. Secondly, a card that is not enable of validating the cardholder (payer) 
pfOine (i.e., a card that only contains the VSDC application). In this case the 
cardholder client device softwaire on the browser prompts the cardholder for secret #3 
(his or her password) and it is provided to the ACS to achieve cardholder 
authentication. 

The flow related to the cardholder client device software after it is given 
control from the ACS (after tiie ACS has received the PAReq message from the 
merchant plug-in) will now be presented. The cardholder cHent device software 
should first determine if the cardholder's PC is chip card enabled (chip card reader 
and client software components present). If it is not, the transaction is processed via 
core payer authentication. If the PC is chip card enabled, then in step 2, obtain the 
secret #2 via the Access appUcation on the chip card or obtain the secret #3 via a 
prompt to the cardholder. 

If secret #2 and UID or secret #3 is provided. Call the VSDC plication on 
flie chip to: retrieve tiie Magnetic Stripe Image (MSI) data element, retrieve the chip 

49 



01B2246A2.L> 



wo 01/82246 



PCT/U 801/13382 



data necessary to allow the ACS to regenerate the cryptogram, and generate the 
ARQC cryptogram. If secret #2 or #3 is not provided, the VSDC applet is not called. 

Send the following data to the ACS for card authentication: the ARQC 
_ cryptogram, magnetic stripe image (MSI), and the data to support the cryptogram 

5 regeneration by the ACS. Optionally, the MSI data can be read. 

Then send secret it2 and UID or secret #3 to the ACS for cardholder 
authentication. 

Generally, it is noted that chip cardholders will be allowed to conduct 
purchase transactions on the Intemet without the card being present via core payer 

10 authentication (PAS without the chip card and chip card reader components). Also, 
the cardholder client device software distributed by the issuer should support all types 
of VSDC cards. Authentication should accommodate chip-based payment 
applications that implement the full and limited versions of Visa Smart Debit or 
Credit applets. Initially the chip-based payment application deployed will sujqjort 

15 limited VSDC features on an Open Platform card. This limited VSDC payment 
applet, "jimip start", supports the following subset of the "full" VSDC features: MSI, 
Onliue Card Authentication, and offline Static Data Authentication (SDA). However, 
SDA is not performed during Intemet transactions. All information from the 
transaction should be forgotten by the payer authentication cardholder client device 

20 software at the end of the transaction.(Such as at the time the PARes message is sent 
to the merchant). 

The ACS is configurable by the issuer to allow different actions to be taken 
when the cardholder client device software is not available or is not able to read the 
chip card. Option #1, the ACS will prompt tihe cardholder to manually enter secret #3 
25 or option #2, no authentication is conducted and a '^ot sqpplicable" response is 
returned to the merchant 

Chip cardholders will be allowed to conduct purchase transactions on the 
Intemet without the card being present (for example, from a different PC without the 
cardholder client device software and chip card reader). The cardholder would 
30 manually complete the merchant check out form (or use other non-chip method) and 
will be prompted by the ACS to manually enter secret #3 if the issuer chose this 
approach. 
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PREFERRED PAYMENT NETWORK 

FIG. 14 illustrates a teleconnnunications network 800 suitable for 
implementing an embodiment of the present invention. The pr^ent invention may 
5 make use of any suitable telecommunications network and may involve different 
hardware, different software and/or different protocols then those discussed below. 
The below-described network is a preferred embodiment of the telecommunications 
network 126 of FIG. 1. Network 800 is a global teleconununications network that 
supports purchase and cash transactions using any bankcard, travel and entertainment 
10 cards, and other private label and proprietary cards. The network also supports ATM 
transactions for other networks, transactions using paper checks, transactions usrag 
smart cards and transactions using other financial instruments. 

These transactions are processed through the network's authorization, clearing . 
and settlement services. Authorization is when an issuer approves or declines a sales 
15 transaction before a purchase is finalized or cash is dispersed. Clearing is when a 
transaction is delivered firom an acquirer to an issuer for posting to the customer's 
account. Settlement is the process of calculating and determining the net financial 
position of each member for all transactions that are cleared. The actual exchange of 
fimds is a separate process. 

20 Transactions can be authorized, cleared and settled as either a dual message or 

a single message transaction. A dual message transaction is sent twice — the first time 
witii only information needed for an authorization decision, an again later with 
additional information for clearing and settlement A single message transaction is 
sent once for authorization and contains clearing and settlement information as well. 

25 Typically, authorization, clearing and settlement all occur on-line. 

The main components of telecommunications network 800 are interchange 
centers 802, access points 804, 806 and processing centers 808 and 810. Other 
entities such as drawee banks and third party authorizing agents may also coimect to 
the network throujgh an access point. An interchange center is a data processing 
30 center that may be located anywhCTe in the world. In one embodiment, there are two 
in the United States and one each in the United Kingdom and in J^an. Each 
interchange center houses the conq)uter system that performs the network transaction 
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processing. The interchange center serves as the control point for the 
telecommunication facilities of the network, which comprise high speed leased lines 
or sateUite connections based on IBM SNA protocol. Preferable, lines 820 and 822 
that connect an interchange center to remote entities use dedicated high-bandwidth 
5 telephone circuits or satellite connections based on the IBM SNA-LUO 
coromunication protocol. Messages are sent over tiliese lines using any suitable 
implementation of the ISO 8583 standard. 

An access point 804 or 806 is typically a small computer system located at a 
processing center that interfaces between the cCTter's host computer and the 
10 interchange center. The acccss.point facilitates the transmission of messages and files 
between the host and the interchange center supporting the authorization, clearing and 
settlement of transaction. Links 826 and 828 are typically local links within a center 
and use a proprietary message format as prefer by the center. 

A data processing center (such as is located within an acquirer, issuer, or other 
15 entity) houses processing systems that support merchant and business locations and 
maintains customer data and billing systems. Preferably, each processing center is 
linked to one or two interchange centers. Processors are connected to the closest 
interchange, and if the network experiences interruptions, the network automatically 
routes transactions to a secondary interchange center. Each interchange center is also 
20 linked to all of the other interchange centers. This linking enables processing centers 
to communicate with each other through one or more interchange centCTS. Also, 
processing centCTS can access the networks of other programs through the interchange 
center. Further^ the network ensures that all links have multiple backups. The 
connection from one point of the network to another is not usually a fixed link; 
25 instead, the interchange center chooses the best possible path at the time of any given 
transmission. Rerouting around any faulty link occurs automatically. 

FliQ. 15 illustrates systems 840 housed within an inteirchange center to provide 

on-line and off-line transaction processing. Por dual message transaction, 

authorization system 842 provides authorization. System 842 supports on-line and 

30 off-line functions, and its file includes internal systems tables, a customer database 

and a m^chant central file. The on-line fimctions of system 842 support dual 

message authorization processing. This processing involves routing, cardholder and 

card verification and stand-in processing, and other fimctions such as file 
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maintenance. Off-line functions including rq)orting, billing, and generating recovery 
bulletins. Reporting includes aufhorization reports, exception file and advice file 
rqjorts, POS reports and billing reports. A bridge firom system 842 to system 846 
makes it possible for membei^ using system 842 to communicate with members using 
5 system 846 and access the SMS gateways to outside networks. 

eiearing and settleinent system 844 clears and setttes previously authorized 
dual message transactions. Operating six days a week on a global basis, system 844 
collects financial and non-financial information and distributes reports between 
members. It also calculates fees, charges and settlement totals and produces reports 
10 to he^ with reconciliation. A bridge forms an interchange between system 844 
processing centers and systCTi 846 processing centers. 

Single message system 846 processes full financial transactions. System 846 
can also process dual message authorization and clearing transactions, and 
communicates with system 842 tising a bridge and accesses outside networks as 

15 required. System 846 processes Visa, Plus Interlink and other card transactions. The 
SMS files comprise internal system tables that control system access and processing, 
and the cardholder database, which contains files of cardholder data used for PIN 
verification and stand-in processing authorization. System 846 on-line functions 
perform real-time cardholder transaction processing and exception processing for 

20 authorization as well as fiill financial transactions. System 846 also accumulates 
reconciliation and settlement totals. System 846 off-line functions process settlement 
and funds transfer requests and provide settiement and activities reporting. 
Settlement service 848 consolidates the settlement functions of systraa 844 and 846, 
including Interlink, into a single service for all products and services. Clearing 

25 continues to be performed separately by system 844 and system 846. 

FIG. 16 illustrates another view of the components of telecommunications 
network 800. Integrated payment system 850. is the piimaiy system for processing all 
on-Kne autiiorization and financial request transactions. System 850 reports both dual 
message and single message processing. Jn both cases, settiemmt occurs separately. 
30 The three main software components are flie common interface Amotion 852, 
authorization i^/stem 842 and single message system 846. 
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Coxmnoii interj&ce function 852 determines the processing required for each 
message received at an interchange center. It chooses the appropriate routing, based 
on the source of the message (system 842, 844 or 846), the type of processing request 
and the processing netwoik. This component performs initial message editing, and, 
5 when necessary, parses the message and ensures ttiat the content complies with basic 
message constraction rules. Function 852 routes messages to their system 842 or 
system 846 destinations. 



COMPUTER SYSTEM EMBODIMENT 
10 FIGS. 17A and 17B illustrate a concq>uter system 900 suitable for 

implementing embodiments of the present invention. FIG- 17A diows one possible 
physical forai of the computer system. Of course, the conqputer system may have 
many physical forms ranging from an integrated circuit, a printed circuit boa^^ 
small handheld device up to a huge super computer. Computer system 900 includes a 
15 monitor 902, a display 904, a housing 906, a disk drive 908, a keyboard 910 and a 
mouse 912, Disk 914 is a computer-readable medium used to transfer data to and 
from coruputer system 900. 

FIG, 17B is an example of a block diagram for computer system 900. 
Attached to system bus 920 are a wide variety of subsystems. Processor(s) 922 (also 

20. referred to as central processing units, or CPUs) are coupled to storage devices 
including memory 924. Mraaory 924 includes random access memory (RAM) and 
read-only memory (ROM). As is well known in the art, ROM acts to transfer data 
and mstractions uni-directionally to the CPU and RAM is used typically to transfer 
data and instructions in a bi-^ectional manner. Both of these types of memories 

25 may include any suitable of the computer-readable media described below. A fixed 
disk 926 is also coupled bi-directionally to CPU 922; it provides additional data 
storage capacity and may also include any of the computer-readable media described 
below. Fixed disk 926 may be used to store programs, data and the like and is 
typically a secondary storage medium (such as a hard disk) that is slower than 

30 primary storage. It will be appreciated that the infc«mation retained within fixed disk 
926, may, in appropriate cases, be incorporated in standard fashion as virtual memory 
in memory 924. Removable disk 914 may take the form of any of the con^uter- 
readable media describe below. 
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CPU 922 is also coiq>led to a variety of input/output devices such as display 
904, keyboard 910, mouse 912 and speakers 930. In general, an input/output device 
may be any of: video displays, track balls, mice, keyboards, microphones, touch- 
sensitive displays, transducer card readers, magnetic or pq>er tape readers, tablets, 
5 styluses, voice or handwriting recognizers, biometrics readers, or other computers. 
CPU 922 optionally may be coiq)led to another computer or telecommunications 
network using network interfece 940. With such a network interface, it is 
contemplated that the CPU might receive information from the netwoik, or might 
output information to the network in the course of performing the above-described 
10 method steps. Furthermore, method embodiments of the present invention may 
execute solely upon CPU 922 or may execute over a network such as the Internet in 
conjunction with a remote CPU that shares a portion of the processing. 

In addition, embodiments of the present invention finiher relate to computer 
storage products with a computer-readable medium that have computer code thereon 

15 for performing various computer-implemented operations. The media and computer 
code may be those specially designed and constructed for the purposes of the present 
invention, or they may be of the kind weU known and available to those having skill 
m the computer software arts. Examples of computer-readable media iaclude, but are 
not limited to: magnetic media such as hard disks, floppy disks, and magnetic tape; 

20 optical media such as CD-ROMs and holographic devices; magneto-optical media 
such as floptical disks; and hardware devices that are specially configured to store 
and execute program code, such as sqpplication-specific integrated circuits (ASICs), 
programmable logic devices (PLDs) and ROM and RAM devices. Examples of 
conq>uter code include machine code, such as produced by a compiler, and files 

25 containing higiher level code that are executed by a computer using an interpreter. 

While this invention has been described in terms of several preferred 
embodiments, there are alteration, permutations, and equivalents, which fall within 
the scope of this invention. It should also be noted that there are many altemative 
ways of implemeating the methods and apparatuses of the present invention. It is 
30 therefore iatended that the following appmded claims be interpreted as including all 
such alterations, pOTnutations, and equivalents as fall within the true spirit and scope 
of the present invention, 
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CLAIMS 

We claim: 

1 . A method for authenticating the identity of a cardholder during an online 
transaction comprising: 

querying an access control server to detennine if said cardholder is enrolled in 
a payment authentication service; 

requesting a password from said cardholder; 

verifying said password; and 

notifying a merchant of the authenticity of the cardholder if the password 
entered by said cardholder is verified. 

2. A method for autiienticating the identity of a cardholder utilizing a chip card 
comprising: 

verifying that said cardholder cUent device includes a chip card reader; 

prompting said cardholder to enter said chip card into said chip card reader; 

receiving a chip card cryptogram that was generated by said chip card based 
upon information in said chip card; . 

receiving a password entered by said cardholder; 

independently generating a second cryptogram based upon information in said 
chip card; 

cornparing the chip card cryptogram to the second cryptogram to determine 
the authenticity of the chip card; and 

verifyiiig said password to authenticate the identity of said cardholder. 
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